1. Field of the Invention
The present invention generally relates to graphics systems, and more particularly to an enhanced cache controller/traverser in a programmable hierarchical interactive graphics system (PHIGS).
2. Discussion of the Related Art
Computer graphics systems are commonly used for displaying graphical representations of objects on a two-dimensional video display screen. Current computer graphics display systems provide highly detailed representations and are used in a variety of applications. A computer graphics display system generally comprises a central processing unit (CPU), system memory, a graphics machine and a video display screen.
In typical computer graphics display systems, an object to be presented on the display screen is broken down into graphics primitives. Primitives are basic components of a graphics display and may include points, lines, vectors and polygons (e.g., triangles and quadrilaterals). Typically, a hardware/software scheme is implemented to render, or draw, the graphics primitives that represent a view of one or more objects being represented on the display screen.
Generally, the primitives of the three-dimensional object to be rendered are defined by the host CPU in terms of primitive data. For example, when the primitive is a triangle, the host computer may define the primitive in terms of the X, Y and Z coordinates of its vertices, as well as in terms of the red, green, blue and alpha (R, G, B and .alpha.) color values of each vertex. Alpha is a transparency value. Additional primitive data may be used in specific applications. Rendering hardware interpolates the primitive data to compute the display screen pixels that represent each primitive, and the R, G, B and .alpha. values for each pixel.
The graphics machine generally includes a geometry accelerator, a rasterizer, a frame buffer controller and a frame buffer. The graphics machine may also include texture mapping hardware. The geometry accelerator receives vertex data from the host CPU that defines the primitives that make up the view to be displayed. The geometry accelerator typically comprises a transform component which receives vertex data from the CPU, a clipping component, an illumination component, and a plane equations component. The transform component performs transformations on the vertex data received from the CPU, such as rotation and translation of the image space defined by vertex data. The clipping component clips the vertex data so that only vertex data relating to primitives that make up the portion of the view that will be seen by the user is kept for further processing. The illumination or lighting component calculates the final colors of the vertices of the primitives based on the vertex data and based on lighting conditions. The plane equations component generates floating point equations which define the image space within the vertices. The floating point equations are later converted into fixed point equations and the rasterizer and texture mapping hardware generate the final screen coordinate and color data for each pixel in each primitive.
The operations of the geometry accelerator are computationally very intense. One frame of a three-dimensional (3-D) graphics display may include on the order of hundreds of thousands of primitives. To achieve state-of-the-art performance, the geometry accelerator may be required to perform several hundred million floating point calculations per second. Furthermore, the volume of data transferred between the host computer and the graphics hardware is very large. The data for a single quadrilateral may be on the order of, for example, 64 words of 32 bits each. Additional data transmitted from the host computer to the geometry accelerator includes illumination parameters, clipping parameters and any other parameters needed to generate the graphics display.
Various techniques have been employed to improve the performance of geometry accelerators. A known way of improving the throughput of a geometry accelerator is to minimize the overall amount of data that must be processed by it. One way that this has been done is to minimize redundancy in the data being sent to the geometry accelerator. This is accomplished by operating on graphics data upstream of the geometry accelerator to reduce the amount of data sent to the geometry accelerator.
Having described the general aspects of all pipelined graphics systems, there are certain attributes that are characteristic of two different types of pipelined graphic systems. A first type operates to process that is presented to the pipeline from an Application Programming Interface (API) in a manner similar to that provided by OpenGL. A second type, however, is configured to receive primitive data and attribute data, or attribute types. The present invention is directed to the improvement of graphics systems of the latter type.
One such system is known as programmable hierarchical interactive graphics system (PHIGS). A problem generally encountered in this type of graphics system is manifest in excessive slowdown of the graphics pipeline due to the processing of the redundant attribute types. For example, consider a graphic pipeline that must process the following code segment;
Set line color (green) PA1 Set line type (solid) PA1 Set line width (2.0) PA1 Set surface color (blue) PA1 Polyline ( . . . ) PA1 Set line color (green) PA1 Set line type (dashed) PA1 Set line width (2.0) PA1 Set surface color (red) PA1 Polyline ( . . . )
In the foregoing example, it is recognized that after the first "Polyline" primitive is drawn, the following "Set line color" and "Set line width" commands are redundant to those previously provided in connection with the first "Polyline" primitive. However, as is known in the prior art, all of the attribute types coded in a code segment are generally sent to the graphics pipeline where they are processed. The processing of redundant attribute types (which need not be described herein, as it is understood by those skilled in the art) demands excessive processing by the graphics pipeline, and therefore wastes valuable processing time. While the foregoing example illustrates minor redundancy in attributes delivered to the graphics pipeline, in practice such redundancies are often much worse. Particularly, due to looping, branching, or other execution in a particular software application, many graphic attributes may be set and reset (to a different value) before actually encountering a graphic primitive that is to be drawn on a display.
Therefore, it is desired to provide an improved pre-pipeline processor for implementation in an attribute-type graphics pipeline system.